Fuzzing is a software testing technique for finding bugs. We might be able to use the bugs we’ve found as exploits.

We run the program many times on abnormal/malformed inputs, looking for unintended behaviour.

We need to be able to measure side effects.

Input Generation

Mutation Based

We mutate seed inputs to create new test inputs - simply strategy is to randomly choose an offset and change the byte.

Pros

• Easy to implement
• Low overhead

Cons

• Highly structured inputs will become invalid quickly, meaning low coverage

Generation (Grammar) Based

• Learn/create the format/model of the input
• Generate new inputs based on the learned model
• Works well for well-known file formats

Pros

• Highly effective for complex structured input parsing applications -> high coverage

Cons

• More complicated

Application Monitoring

Blackbox - Only the interface is known. Whitebox - Application itself can be analysed/monitored

Evolutionary Fuzzing

Rather than throwing inputs, evolve them. We start with an input, mutate it, execute and monitor edge cases. If it produces an edge case, add it to our list of inputs, otherwise, mutate it further. Usually code coverage is used as the metric to evaluate the effectiveness of mutation.

Directed Fuzzing

Not a very explored field. Uses methods to determine which direction the fuzzing should go in based on heuristics such as how much of an impact evolution in that direction is having.

Further Reading

• What you see is not what you execute by G. Balakrishnan et. al.
• https://pages.cs.wisc.edu/~bart/fuzz/Foreword1.html